1. Field of the Disclosure
The disclosure generally relates to a proximity request validating method, a UE using the same method, an identity request method, and a network entity using the same method.
2. Description of Related Art
In the field of D2D communication which is often referred to as a Proximity-based Services (ProSe) communication, a UE typically may directly discover another UE and subsequently perform D2D communication with another UE with or without the assistance of a core network such as an Evolved Packet Core (EPC). In a proximity discovery procedure, a ProSe-enabled UE may transmit a proximity request in order to discovering another ProSe-enabled UE are described in 3GPP TS 23.303 which is incorporated by reference herein. When the proximity discovery procedure occurs in the EPC-level, the proximity discovery procedure would involve a proximity request validation procedure by which a network entity such as a ProSe function in the EPC network would ask the a targeted UE to confirm a permission for the proximity request if a profile of the targeted UE indicates that the proximity request need to be explicitly validated described in 3GPP TS 24.334 which is incorporated by reference herein. The ProSe Function is the logical function that is used for network related actions required for ProSe. The ProSe Function plays different roles for each of the features of ProSe.
A proximity discovery procedure may involve different types of identifiers (ID). A network level user ID such as an EPC ProSe user ID (EPUID) is an identifier for EPC-level ProSe discovery and EPC support of WLAN direct communication to uniquely identify a UE registered for ProSe. This identifier could occasionally be reassigned by the ProSe Function in an EPC network. An application Layer User ID (ALUID) is an identifier that identifies a user within the context of specific application.
FIG. 1 shows a general call flow of a EPC-level ProSe discovery procedure which is consistent with 3GPP TS 23.303 for example. In step S110 and S120, in order to order to obtain ProSe service, UE A and UE B would perform UE registration for ProSe or D2D communication with the ProSe Function A and ProSe Function B residing in their respective home public land mobile networks (Home PLMNs), respectively. In step S130 and S140, in order to check an authorization of the requested application the ProSe function (such as the ProSe Function A and the ProSe Function B) and request the APP server to register UE's ALPUID with an EPUID, UE A and UE B would perform application registration for ProSe with the ProSe Function A and the ProSe Function B residing in their respective Home PLMNs, respectively. In step S150, UE A would make a proximity request (to possibly indicate a window of time during which the proximity request is valid) for UE B. For example, UE A might be alerted for proximity with UE B. In response to the proximity request, ProSe Function A would request for a location update for UE A and for UE B. The location updates could be periodic or could be based on a triggered event or both. In order to request location updates for UE A, ProSe Function A would contact the SUPL Location Platform (SLP) A. Similarly, in order to request a location update for UE B, ProSe Function A would contact ProSe Function B, which would request a location update for UE B from SLP B.
In step S160 and S170, the locations of UE A and UE B could be reported to their respective ProSe Functions intermittently. ProSe Function B may forward the updates of the locations of UE B to ProSe Function A based on conditions set by ProSe Function A. Whenever ProSe Function A receives the updates of the locations of UE A and/or UE B, Prose Function A may perform proximity analysis for the locations of UE A and UE B. In step S180, when ProSe Function A detects that UE A and UE B are in proximity, ProSe Function A would informs UE A that UE B is in proximity and may optionally provide UE A with an assistance information for WLAN direct discovery and communication with UE B. Similarly, ProSe Function A would inform ProSe Function B, which in turn would inform UE B of the detected proximity of UE A. The Prose Function B may also optionally provide UE B with the assistance information for WLAN direct discovery and communication with UE A.
FIG. 2 is a flow chart which illustrates an example of an EPC-level proximity request procedure. In step S210, UE A sends a Proximity Request message to ProSe Function A. In response to receiving the Proximity Request message, in step S220, ProSe Function A would perform a proximity map request procedure with the APP server. The Proximity map request procedure is used for requesting the EPUID of UE B for which UE A shall get alerts when in proximity of UE B, and the identity of the ProSe Function (PFID) for UE B as well. In step S230, ProSe Function A propagates the Proximity Request message with EPUID of UE B to ProSe Function B. Based on EPUID_B received in the step S230, ProSe Function B retrieves UE B's record. In step S250, the proximity request validation procedure would be performed depending on UE B's ProSe profile, UE B may be asked to confirm permission for the proximity request. In step S260, ProSe Function B requests location reporting on UE B from SLP B and acknowledges the proximity request to ProSe Function A and provides UE B's current location (if known). In step S280, ProSe Function A requests location reporting on UE A from SLP A. If UE A's current location is available and if UE B's location was included in step S260, ProSe Function A may decide to cancel the Proximity Request procedure if it determines that the UEs are unlikely to enter proximity within the requested time window. Otherwise, ProSe Function A acknowledges the proximity request to UE A (S290). Examples of the proximity request procedure are described in 3GPP TS 23.303 and TS 24.334 which are incorporated by reference herein, and the detailed descriptions would be described later.
However, in the aforementioned EPC-level ProSe discovery procedure and the proximity request procedure, there could be two issues. The first issue is that the targeted UE such as UE B in FIG. 1 and FIG. 2 may not know who has made the proximity request. For example, as a social network application is executed on UE A in FIG. 2, and the UE A has received an operation for chatting with a friend such as a user of UE B in FIG. 2. In response to receiving the operation, UE A would send the proximity request to ProSe Function A. Then, ProSe Function A would ask UE B for validating the proximity request. However, UE B would receive a chatting request notification for accepting or rejecting to chatting without knowing the identity of UE A.
The second issue is that execution of the proximity request validation procedure might be stuck because the targeted UE does not respond to the proximity request such as by given a permission or denial for the incoming proximity request. Assuming that a user of the targeted UE is in busy or does not notice the incoming request, the proximity request validation procedure might not be able to proceed properly.